I have an array of values to be written to cookies. However, given the 4KB limit on cookies and the fact that the total length of the array may be longer than that, I cannot simply store the serialized value in an array.
Could I do something as simple as this? (not tested)
<?php
//$array is the array of values
$serialized = serialize($array);
$serializedArray = str_split($serialized,4096); //Is the 4096 correct?
$arr_length = count($serializedArray);
for ($i=0;$i<$arr_length;$i++) {
setcookie("cookie[$i]", $serializedArray[$i], time()+3600);
}
Would there be any problems encountered? Is there a better way to achieve this?
I don't see anything wrong with that in principle, but you will get great data compression on the output from serialize because it is all utf-8.
Here's snippents from a piece of code that I wrote for doing a very similar thing to what you want:
Compression:
$compressed = gzcompress(serialize($array), 9);
Decompression:
$array = unserialize(gzuncompress($compressed));
As an example, I can use this to compress an object that serializes into a string of 400Kb down to about 17Kb (so you might be able to compress your serialized array into a single cookie).
The degree of compression that you will get is dependent upon the structure of the string. If you are really interested in the nuts and bolts, the details are here: http://www.faqs.org/rfcs/rfc1950 (I have never looked at this!).
The only problem I might imagine here is that $compressed contains a binary string, I don't know if the PHP cookie mechanism likes binary strings ... you may need to escape non-printing chars (I am thinking of \0 in particular!).
Thanks for the tip! I will certainly use gzcompress in my final code. Does the compression actually translate to the cookie though? From memory, some characters need to be escaped. Does that apply here, and will it negate the benefits of compression?
Yes, I mentioned that! I'd try it without escaping first, and only escape if it does cause problems.
I have used escaping before in a similar situation, All I did was to escape non-printing characters only. To do so, I expanded each non-printing char into it's hex equivalent string (e.g. "4" for EOT, "15" for NAK, etc) and prefixed each hex string with the printing character returned by chr(0x80). In my experience, 0x80 is pretty harmless! For coookies you may only need to escape characters like NUL, EOT, ESC, etc as well as any printing characters that may indicate some kind of instruction when placed in a cookie.
The only downside is that in the worst case you will get 2-3 times data expansion (but you can get 90%+ compression in the first place!).
Sorry, I didn't see your edit.
I've just seen this on the PHP manual:
Cookies names can be set as array names and will be available to your PHP scripts as arrays but separate cookies are stored on the users system. Consider explode() to set one cookie with multiple names and values. It is not recommended to use serialize() for this purpose, because it can result in security holes.
What security holes?
There's an often-quoted saying that's along the lines of "if you have to ask what the limits are you're probably doing something wrong". What on earth are you storing in cookies such that the size restrictions are causing a problem? Take the hint, and come up with a different solution - you have (some proportion of) your web-server's hard-drive at your disposal, why not make use of that instead and just give the client the 'key'?